Backing Up with the dump Utility (part 1) - Syntax of the dump Command & The Options to the dump Command

To use dump and restore for regular system backups, you need to understand the following:

• How to use dump to back up a filesystem (with the appropriate options)

• How the backup ends up on the volume

• How to get the table of contents of a dump volume

• How to manipulate the volume and restore from a backup created by dump

• The limitations of dump and restore

• What you should be doing if you are using dump on a regular basis

The first thing to understand is what your dump command is and what its options are. See Table 3-1 for a listing of dump commands on various Unix versions. The following section is essentially a unified manpage for these dump-like commands on specific operating systems.

(r)dump

ufsdump

xdump

dump

dump

1. Syntax of the dump Command

Let’s start with the basic dump command:

#  dump levelunbdsf blkg-factor density size device-name file_system

The following are examples of running this command:

• To create a full backup of /home to a local tape drive called /dev/rmt/0cbn:

• #  dump 0unbdsf 126 141000 11500 /dev/rmt/0cbn /home

  
  

• To create a full backup of /home to an optical or CD device called /backup/home.dump:

• #  dump 0unbdsf 126 141000 11500 /backup/home.dump /home

  
  

• To create a full backup of /home to the remote tape drive /dev/rmt/0cbn on elvis:

• #  (r)dump 0unbdsf 126 141000 11500 elvis:/dev/rmt/0cbn /home

  
  

The preceding commands use three options (0, u, and n) that do not require arguments and four options (b, d, s, and f) that require a “companion” argument.

The dump command accepts as its first argument a list of options, then each option’s argument is placed on the command line in the same order in which the options are listed. Figure 1 illustrates how the dump command options relate to their companion arguments.

2. The Options to the dump Command

The dump utility has seven main options that are available on most platforms:

0-9

Specifies the level of backup that dump should perform.

b

Specifies the blocking factor that dump should use.

u

Tells dump to update the dumpdates file.

n

Tells dump to notify the members of the Operator group when a dump is completed.

d and s

Tells dump how large the backup volume is. dump uses these numbers to estimate how much “tape” is available.

f

Tells dump what device to use.

W, w

Tells dump to perform a dry run that tells you what filesystems need to be backed up (these are seldom used).

If you are using dump for regular system backups, you should be using most of the preceding options. It is important to note that many of these options have default values, eliminating the need to specify that option and its argument in the dump command. For example, the default backup level is usually 9. The problem with the default values is that they vary between operating systems and may also vary even on the same operating system, depending on factors such as media type. It is better to specify each of these options the same way on all your dump backups to simplify making restores at a later date.

2.1. Specifying a complete or incremental backup (0–9)

The first argument that you can specify is the dump level; you can use any number from 0 to 9. Incremental dumps refer to the dumpdates file for the date of the last lower-level backup.For example, if you are performing a level 5 backup, dump backs up all files that have changed since the last backup that was level 4 or lower. It gets the date of this backup from dumpdates (usually /etc/dumpdates). Since the dumpdates file is needed for incremental backups, you must use the u option to update it.

2.2. Specifying a blocking factor (b)

The b option specifies the number of blocks to write in a single output operation. This refers to the number of physical blocks. The size of the entire block that dump writes depends on the size of the physical block multiplied by the blocking factor. For most versions of Unix, the physical block size for dump is 1024 bytes. So, if you specify a blocking factor of 10, the size of the actual block that dump writes is 10,240, or 10 K. This option is not available on SCO.

2.3. Updating the dumpdates file (u)

The u option causes dump to update the dumpdates file for the filesystem that you backed up. (The dumpdates file is usually /etc/dumpdates, but is /var/adm/dumpdates on HP-UX 10.x.) This is a plain-text file that lists each filesystem’s raw device and the date that the last backup of each level was taken on that device. Here is an example /etc/dumpdates file taken from a Solaris box:

/dev/rdsk/c0t1d0s0               0 Sun Apr 30 23:07:22 2006
/dev/rdsk/c0t1d0s0               1 Wed May  3 02:49:51 2006
/dev/rdsk/c0t3d0s0               0 Sat May 20 00:31:49 2006
/dev/rdsk/c0t3d0s0               1 Mon May 29 01:33:33 2006
/dev/rdsk/c0t3d0s0               5 Wed May 31 00:28:14 2006

You can see that device c0t1d0s0 had a level 0 backup on April 30, and a level 1 backup on May 3, 2006. Device c0t3d0s0 had a level 0 backup on May 20, a level 1 on May 29, and a level 5 on May 31.

There are a few important things to note about the dumpdates file. The first time you run dump on a system, you must first create an empty dumpdates file, and it must be owned by root. If it is not there or is not owned by root, dump does not create it. Your dump continues, but it will complain. Note that dumpdates is updated only if the entire dump completes successfully. If any errors cause dump to abort, dumpdates is not updated. This means that it is a good file to use for an automated script that checks to see if your dumps worked. The following list shows the various names and locations of the dumpdates file:

• HP-UX 9.x, SunOS, Solaris, AIX, Linux, IRIX: /etc/dumpdates

• HP-UX 10.0: /var/adm/dumpdates

• SCO: /etc/ddate

You might not want to use the u option when making a special “one-time” backup volume, because doing so changes the behavior of other backups. For example, if you are making a one-time level 0 backup for someone and use the u option, your automated level 1 backups will reference that level 0 backup that has been given to someone else and is not a part of your normal backup pool.

2.4. Notifying your backup operators (n)

The n option causes dump to notify everyone in the operator group, as specified in the /etc/group file, if a dump backup requires attention. This notification looks similar to a wall message. (This option is not available on SCO.) A dump backup may require attention when any of the following occurs:

• A dump backup reaches the end of a tape, or your CD fills up.

• A backup drive malfunctions, causing write errors.

• There are difficulties reading from the disk drive.

2.5. Specifying density and size (d and s)

The density (d) and size (s) options do not affect how data is written to the backup media. The dump command uses them only to determine how much data can fit on a given volume and to determine when it has reached the logical-end-of-tape (LEOT, or the point at which dump thinks the volume is full) before it reaches the physical-end-of-tape (PEOT). dump then prompts the operator to switch volumes. The logic behind this is to keep the volume from hitting PEOT, because older versions of dump do not handle this well. Here is a quick explanation of these two flags:

d (density)

By specifying a density, you are telling dump how much data fits on one inch of tape. (This value is really a throwback to the nine-track tape days, but dumps option to figure out how large the backup volume is.) If you want to make sure that dump uses the entire volume, use a large value such as 80,000. uses it in combination with the

s (“tape” size in feet)

This option tells dump how long the tape is. It then calculates how much data fits on the tape using the values provided for size and density. If you want to make sure that dump uses the entire volume, use a large value like 500,000. Using 80,000 as the density and 500,000 as the size effectively tells dump that your volume is capable of storing 480 GB! (Yes, this and the d option both seem silly if you’re backing up to disk or CD, but they are important. See the following section “Do I have to use the s and d options?” for more information.)

In actual practice, these options are very difficult to use and yield very little value. Most people fake out dump using values that make dump think it will never run out of tape. This causes dump to use the entire volume and lets it discover the PEOT if or when it gets that far. There are many reasons for this:

• The dump command can now detect and handle PEOT (dump used to abort upon reaching PEOT). In Solaris, they even have an option that causes the tape to eject, and if you are using an autochanger, it then inserts the next tape. On Solaris, therefore, dump could then continue without intervention.

• The calculations work only if it’s the only backup that dump has put on the volume. (For example, each time you use dump, you tell it the tape is 10,000 feet long. If you have already put at least one backup on the volume, it’s no longer 10,000 feet long).

• If you were to use “real” values, you would probably have a small density value with a very large size value. Many Unix versions tell you that doing this can cause problems. (I’m serious. You have to make them up!)

• If you want dump to actually stop before PEOT, you need to underestimate the values, which results in using less space than the volume actually has. (Some budgets necessitate using every inch of every volume that you paid for.)

Adding compression into the calculation really complicates the process, since compression is one area in which the phrase “your mileage may vary” really applies.

2.6. Do I have to use the s and d options?

A few newer versions of dump have done away with these options and provided a new size in kilobytes option you can use to specify the size of the volume in kilobytes. Even so, I personally use the s and d options with every dump command I run so that I don’t have to remember how different versions work. The more per-host and per-OS customization you do, the more trouble you can get into. (For example, the size in kilobytes option uses a different letter on each version of Unix that supports it!) In this case, using the archaic size and density options actually makes writing shell scripts much easier, because you can use the same options on most versions of Unix.

What happens, then, if you don’t use the s, d, or size in kilobytes options? On some Unix flavors, dump uses the default values for size and density (except for AIX, which has apparently done away with these options altogether). Unfortunately, the default values are usually set to work with a nine-track tape. (Solaris has changed its default values to be slightly more sensible.) If this happens, dump will think it needs several volumes. The output of dump looks something like the following:

DUMP: Estimated 5860 blocks (3006KB) on 39.00 tapes.

Notice that it thinks it’s going to need 39 tapes. This is what can happen if you do not use the size and density options to specify the capacity of the volume. As mentioned before, you can easily disable this feature by setting these values to some ridiculously high figure so that dump never thinks that it has run out of tape. (I personally use numbers like 1,000,000 for both.)

2.7. Specifying a backup device file (f)

The f option specifies the name of the backup device to which you are sending the data. (This “device,” of course, could be either an actual tape device or a file sitting on a disk, optical platter, or CD.) If you are expecting to use the hardware compression feature of your tape drive, make sure that you choose a device that supports compression. If you want to send the data to a drive on another system, use the format remote_system_name:device. Most versions of Unix support using remote devices in dump, as long as you’re alright with using rsh as an authentication mechanism.

Remote devices require that the host with the remote device trust this host via the /.rhosts file. If you try to use a remote device from a nontrusted system, you might get the dreaded message:

Permission Denied

To test if you are a trusted host, try issuing the following command as root:

# rsh remote_system uname -a

If it does not work, you need to put a line with this system’s name in the remote system’s ~root/.rhosts file.

Unfortunately, in today’s mixed environments, you don’t always know what other systems think a particular system’s name is. The remote system might be using DNS, NIS, or a local hosts file. When you rsh to a system, it initially sees you as an IP address. It then does a gethostbyaddr(  ) and tries to resolve that address into a name. Depending on how your particular system is set up, it may consult DNS, NIS, or the local /etc/hosts file; the order in which it consults these sources also varies with your setup. If it uses the local hosts file or NIS for address resolution, it may or may not appear with a fully qualified domain name such as apollo.domain.com. If it uses DNS, it appears with the fully qualified domain name. It is important to know this because this is the name you must put into the /.rhostsapollo, and the remote system is elvis. If you want to rsh from apollo to elvis, you should try the easy step first. On elvis, enter this command: file. Suppose your system is called

$ echo apollo >>/.rhosts

If that doesn’t work, apollo appears as something else to elvis (e.g., apollo.domain.com). To find out for sure, you can telnet to elvis from apollo, then use commands such as last, who, tty, or netstat to look at the field that lists the system from which you came. If it turns out to be apollo.domain.com, put that into the /.rhosts file on elvis. (For example, at one client site, it appears as apollo.DOMAIN.COM.) Once you have put the correct name in /.rhosts, rsh should work.

2.8. Displaying which filesystems need to be backed up (W and w)

The W and w dump options are available on most Unix systems and display information about which filesystems need to be backed up. Usually, the w option displays information on all filesystems, while the W option lists only those filesystems that need to be backed up, based on the backup level you have chosen. These options have slight variations between Unix flavors, so read the appropriate manpage.

2.9. Interesting options for Solaris’s ufsdump utility

Solaris’s ufsdump has a few options not found in other versions of Unix. It supports the l (autoloader), o (offline), a (archive file), and v (verify) options:

l

The autoloader option ejects the tape if it reaches PEOT before dump is done. It then waits up to two minutes for the next tape to be inserted. This works well with sequential autoloaders.

o

The offline option merely ejects the tape at the end of the backup, protecting the tape from being overwritten by another process.

a

The archive file option writes dump’s table of contents to archive_ file (as well as writing it to the volume, as all dump commands do). This file can then be used by ufsrestore to see if a file is on a given volume without having to mount that media.

v

The verify option compares the backup to the actual filesystem. While this may sound good in theory, it requires the filesystem to be unmounted, which is not practical in many applications.